Code Attestation with Compressed Instruction Code 



Benjamin Vetter, Dirk Westhoff 
Fakultat Technik und Informatik 
HAW Hamburg 
Hamburg, Germany 
{vetter_b, westhoff}@informatik.haw-hamburg.de 



ABSTRACT 

Available purely software based code attestation protocols 
have recently been shown to be cheatable. In this work we 
propose to upload compressed instruction code to make the 
code attestation protocol robust against a so called com- 
presssion attack. The described secure code attestation pro- 
tocol makes use of recently proposed micro-controller archi- 
tectures for reading out compressed instruction code. We 
point out that the proposed concept only makes sense if the 
provided cost /benefit ratio for the aforementioned micro- 
controller is higher than an alternative hardware based so- 
lution requiring a tamper-resistant hardware module. 
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1. INTRODUCTION 

The evolution of the ubiquitous computing vision towards 
full-fledged real world applications faces a diversity of new 
problems. Besides other issues and due to the fact that 
for many applications due to the large number of involved 
end-devices cost-efficient hardware is an issue, one can not 
guarantee that a code image which once has been uploaded 
on a tiny, non-tamper resistant device, will always run in 
a correct and un-manipulated way. Even worse, it may be- 
have in a Byzantine manner such that the device sometimes 
behaves correctly and sometimes behaves incorrectly. 

One strategy to control respectively detect such misbehaving 
nodes in a sensor network, or, more generally, in an M2M 
setting, is to run from time to time a challenge-response 
protocol between the restricted device and a master device 
- the verifier - that is sending the challenge. 

However, recently it has been shown that purely software 
based code attestation [5], [3], [B] is vulnerable against a 
set of attacks. Basically one can subdivide code attestation 



techniques into two subsets: the first class of approaches is 
using challenge-response protocols in conjunction with harsh 
timing restrictions for the restricted device's response. Oth- 
erwise an attacker could simply load the original code im- 
age into the external memory and save program memory 
for his own bogus code. Each time the master device trig- 
gers the code attestation protocol, for the computation of 
the response the cheated prover device reads the original 
program from the external memory. Since reading from ex- 
ternal memory is much more time consuming, a timing re- 
striction at the verifier for the duration between sending the 
challenge message and receiving the response message can 
detect this. The second proposed class of countermeasures 
randomly fills empty program memory to avoid that such 
free memory space can be used to infect the device with 
bogus code. In their landmark work [7], Castelluccia et al. 
have shown that both types of aforementioned countermea- 
sures can be circumvented. Later we provide more details 
on this. The rest of the paper is organized as follows: Sec- 
tion 2 introduces the adversary model. Section 3 describes 
the so called compression attack the attacker can perform 
to break recently proposed code attestation protocols. In 
Section 4 we propose our countermeasure to deal with com- 
pression attacks and in Section 5 we give insights how to ex- 
ecute compressed instruction code as necessary requirement 
for this approach. Section 6 discusses suitable compression 
algorithms and in Section 7 we provide the security analysis 
of the proposed solution. Conclusions and open issues are 
presented in Section 8. 

2. ADVERSARY MODEL 

After node deployment and before the first round of the at- 
testation protocol starts, the attacker has full control over 
all device memories such that he can modify program mem- 
ory or any other memories like e.g. the external memory. 
At attestation time, when the challenge-response based at- 
testation protocol is running, the attacker has no physical 
control over the restricted device anymore. However, please 
note that the device may yet run malicious code. It is up to 
the code attestation protocol to detect this independently of 
the fact that the attacker may find ways to store the orig- 
inal uploaded code image at a different memory than the 
program memory. Note that we do not consider fluctual 
data memory. Control Flow Integrity could prevent attacks 
that use techniques like Return- Oriented Programming [7], 
[lOj , [11] . Obviously, during the phase in which the attacker 
has full control over the restricted device, the attacker is 
also able to either modify the code for the code-attestation 



protocol itself or to read out any sensitive data like e.g. pre- 
shared keys in case the code attestation protocol would be 
based on this. 



3. COMPRESSION ATTACK 

One major challenge for a purely software-based code at- 
testation for embedded devices is the so called compression 
attack. This attack cheats a basic challenge-response based 
code attestation as follows: the originally uploaded program 
which shall temporarily be checked by the attestation proto- 
col to be exclusively stored in the program memory is sub- 
sequently compressed by the attacker. Depending on the 
concrete compression algorithm and according to the actual 
uploaded code image for a given application the compression 
gain ranges from 12% up to 47% [7]. An attacker can use 
such free program memory to store and run bogus code on 
the node's program memory. Note that current solutions for 
secure code-attestation also propose to fill the free program 
memory with pseudorandomly generated words instead of 
the default entry OFF. This defends against an attacker who 
could use this previously unused memory for uploading a 
bogus code image in an undetected way. Since the afore- 
mentioned pseudorandomly generated words are required to 
be part of the response of a code attestation protocol, the 
verifier needs to know respectively may be able to compute 
such pseudorandomly generated words. 

However, Castelluccia et al. have shown that cheating such 
kinds of attestation protocols is still possible: whenever the 
restricted device (prover) receives a nonce from the master 
device (verifier) it decompresses the earlier compressed orig- 
inal program on-the-fly and subsequently computes the hash 
value X = h{nonce\\CI\\ PRW) by applying the hash func- 
tion h{). The X is the checksum respectively the response of 
the challenge-response protocol. The CI denotes the orig- 
inally uploaded code image and the PRW is the pseudo- 
randomly filled content within the remaining free program 
memory at load-time. Obviously this simple challenge-response 
based code attestation fails: Whenever the prover receives 
a fresh nonce (the master device initiated the code attesta- 
tion protocol), the attacker decompresses the compressed CI 
and writes it into the program memory again. This provides 
all the relevant input parameters for the computation of the 
hash function, namely the CI, the nonce, and the PRW such 
that the master device subsequently receives the response x 
within a given time interval which it verifies to be correct. 
Finally note that, to save his own bogusly uploaded code 
image CI, the attacker could have stored CI also within the 
external memory. Subsequently to the time-critical code at- 
testation phase, he has enough time to again compress the 
CI and read CI from external memory to program memory. 



4. ATTESTATION OF COMPRESSED 
INSTRUCTION CODE 

Our countermeasure against uploading malicious code into 
the program memory and subsequently not being able to 
detect this, re-uses and adapts earlier proposed code attes- 
tation protocols [3], [S], [S] by at the same time using 



a hardware extension at the micro-controller, and 



prover 




Option 1 : 

X = h{nonce\\C(CI)\\PRW) 

Options 2a and 2b : 

X = h{nonce\\CiCI)\\dic\\PRW) 

X = h{nonce\\C{CI)\\LAT\\PRW) 



Figure 1: Derivates of the secure code attestation 
protocol with lossless data compression algorithm. 



ii. fulfilling a strict policy for uploading CIs into the pro- 
gram memory. 

This policy is to only upload a yet compressed code image 
C{CI) into the program memory and to fill the remaining 
part with PT^WQ. Consequently, the attacker cannot allo- 
cate such easily free program memory anymore to tracelessly 
upload malicious code by applying the above described com- 
pression attack. Note that with the proposed approach the 
challenge (a fresh nonce) which goes into the hash computa- 
tion for every run of the code-attestation anew, enforces the 
prover to always compute the hash value (response) with a 
compressed CI and PRW anew. In our proposed setting 
the response x thus is computed as h(nonce\\C{CI)\\PRW) 
where the C is a properly chosen lossless data compression 
algorithm. More details on the properties of the chosen loss- 
less data compression algorithm C and other refinements on 
C{CI) will be provided later. The adapted code attestation 
protocol is shown in Figure 1 (Option 1). 

Please note that still with our proposed adapted code attes- 
tation protocol allowing to upload only a compressed code 
image into the program memory it is essential to enforce a 
runtime restriction as a countermeasure against an attack in 
which the original code image or parts of it are shifted to the 
external memory. We term e as the duration of the time in- 
terval [to, fi] measured by the local clock of the verifier. The 
to denotes the sending time of the challenge nonce and the 
ti denotes the receiving time of the response x. We empha- 
size that a proper choice of the threshold T^m with e < Tem 
is prover device-dependent to defend the approach against 
attacks using the external memory of the prover device. 



5. EXECUTION OF COMPRESSED 
INSTRUCTION CODE 

Now that an attacker cannot such easily cheat the code- 
attestation protocol anymore by simply compressing the orig- 
inally uploaded code image and subsequently decompressing 
it if needed, the remaining problem with this approach is 
how to run compressed code? To solve this issue one needs 

^We decided not to compress the PRW since in fact a 
good choice of the pseudorandomly filled words can not 
be compressed anymore. In fact C{PRW) would result in 
|C(P-RW^)| > |P-RW| eventually providing another attack 
vector to save memory by computing C^^{C{PRW)). 
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a specific manner. Consequently, an attacker could either 
fully overwrite or partially modify the dictionary memory. 
To be able to subsequently decompress the CI at runtime 
we are not allowed to compress the dictionary [die) itself. 
We refine the computation of the response x such that: 



X = h{nonce\\C{CI)\\dic\\PRW) 



(1) 



This additional consideration of the dictionary has also been 
reflected within Figure 1 (Option 2a). 

6. CHOICE OF THE DATA COMPRESSION 

ALGORITHM 
6.1 Envisioned Properties 

The proper choice of a suitable lossless data compression al- 
gorithm C is essential with respect to the proposed security 
architecture. We need to find a lossless data compression 
algorithm which shall provide the following partially con- 
flicting properties: 



Figure 2: Micro-controller architecture with com- 
pressed code memory and dictionary memory [8J. 

to incorporate a hardware extension at the micro-controller. 
Please note that the approach to upload a compressed code 
image into the program memory is not new. It has recently 
been proposed by Yamada et al. [8] . Early work on this can 
be found in 111. 

However, originally it has been proposed with the objec- 
tive to offer a high compression ratio and a fast instruc- 
tion expendability - and not as a building block to protect 
against a bogus code image in the program memory like 
we are proposing. Envisioned is a program memory which 
includes a dictionary memory or other means to start the 
decompression operation. This component is responsible for 
storing instruction codes which appear in a typical program 
image. Figure 2 illustrates the micro-controller architecture 
which is proposed in [8]. Another compression technique 
based on a dictionary has been presented by Lefurgy et al. 
in [2]. 



So we propose to only allow to load yet compressed code 
into the program memory and to decompress the code at 
runtime. The decompression unit is located at the program 
memory with a controller passing compressed code instruc- 
tions to the dictionary memory. This architecture can be 
used to support the defense against attacks where free pro- 
gram memory space can be generated by compressing the 
originally uploaded code image and filling this gap with ma- 
licious code (including the compression/decompression func- 
tion). A code attestation protocol based on simply hash- 
ing the original code image plus the remaining free program 
memory space would not detect such an attack. 

Some Remarks: The dictionary memory as well as the com- 
pressed code memory are regions within the program mem- 
ory. Thus, in particular the dictionary memory is no ded- 
icated memory module, neither separated nor protected in 



1. a high compression ratio for a typical CI (compared 
to competing lossless data compression algorithms); 

2. very fast decompression (vice versa the performance of 
the compression operation can be relatively poor); 

3. the overall decompression concept is required to sup- 
port entry-points at which the decompression opera- 
tion can start; 

With respect to property number one we state that it is one 
of the properties of any lossless data compression algorithm 
that for typical input files containing many frequently used 
data chunks the compression rate is rather high. However, 
vice versa if the input file contains many seldomly used data 
chunks the resulting compression ratio is rather poor. More- 
over, the compression algorithm Ch chosen by the honest 
party should ideally provide the highest compression rate 
compared to other compression candidates, e.g. Ca cho- 
sen by the attacker. Otherwise the attacker could apply 
Ca(Ch(CI)) to save program memory for CI. 

The second property is required since decompression of a 
code image instruction should ideally not delay the execu- 
tion of the originally loaded program. On the contrary there 
is no technical requirement that restricts the compression 
time before uploading the CI. 

Entry points which define the positions at which the de- 
compression operation starts to decompress the next code 
instruction can be either chosen to be placed at fix posi- 
tions of the compressed CI, with a fix and equal distance 
for a compressed chunk representing a single code image in- 
struction. This can be achieved by using a dictionary. A 
complementary approach would be to allow entry points at 
variable positions supporting compression chunks with dif- 
ferent sizes. Clearly the latter provides a better compression 
ratio at the cost of a higher management effort for finding 
the next entry-point. A cache together with a line address 
table (LAT) are frequently used for this [1]. Note that cache 
and LAT can be independently applied of the concretely cho- 
sen compression algorithm. For this reason we prefer a LAT 
instead of a dictionary. Our choice has been refiected in 
Figure 2. 
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Figure 3: Compression ratios for multi-hop oscillo- 
scope program image of typical compression algo- 
rithms for varying blocksizes. 

6.2 Candidates 

Initially we considered Canonical Huffman Encoding (CHE) 
[3] as lossless data compression algorithm C with canonical 
Huffman tree. To handle entry points at variable positions 
with the objective to provide a higher compression rate we 
use a LAT as a list of entry points. Note that with this 
approach a dictionary memory is not required anymore such 
that in Figure 1 Option 2b becomes valid: 

X = h{nonce\\C{CI)\\LAT\\PRW) (2) 

Also, since each entry is listed only one time within the 
LAT, later we show that the attacker does not succeed in 
sufficiently compressing the LAT. It turns out that to a large 
degree this is also true in case the attacker tries to compress 
the canonical Huffman tree. However, the disadvantage of 
the CHE for our purposes is its relatively small gain of com- 
pression results on MicaZ with on average 12.19% for vari- 
ous typical WSN programs [3. For comparison, the lossless 
data compression algorithm Prediction by Partial Matching 
(PPM) provides an average gain of 47.45% for typical WSN 
applications. Unfortunately, such a significant gain differ- 
ence of the compression algorithms CHE and PPM again 
opens the door for an attack to make use of this gain differ- 
ence of approximately 35%. The attacker can apply PPM 
on the compressed code image Cche(CI) and again gener- 
ate free space for his own bogus malicious code in either of 
the two ways: 

1. Ca{Ch{CI)) ■- Cppm{Cche{CI)), respectively 

2. Ca{C-\CniCm := Cppm{Cc'„ACche{CI))) 

C ^ denotes the decompression operation. Due to the afore- 
mentioned reason we also analyzed Defiate, ZPAQ and fur- 
ther derivates of PPM, namely PZIP and PPMZ. Please note 
that the hardware supported compression scheme proposed 
by Wolf et al. 1 doesn't limit the set of lossless compression 
algorithms. It only limits the blocksize Sh, which has to be 
equal to the available cache size (s^ = |cac/ie|). 



Figure 4: Amount of decompressed data for varying 
block sizes during the attestation. 

Figure [3] shows that the chosen algorithms provide varying 
compression ratios depending on the block size Sh- This is 
illustrated for our benchmark code image multi-hop oscil- 
loscope {\CI\ = 25.9KB) which ships with TinyOS. Large 
block sizes provide better compression ratios than small block 
sizes. If we choose and apply a tuple {Ch, Sh) the attacker 
can only gain additional free memory \Ca{Ch{CI))\ — \Ch{CI)\ 
= \CI\ by choosing 

1. Sa > Sh if Ca = Ch, or 

2. otherwise: Sa < Sh (for some {Ca,Sa))- 

Nevertheless, if the attacker chooses a much smaller block 
size the compression ratio will suffer. Therefore, when we 
compress the CI with a larger block size the attacker is 
forced to use a larger block size as well. Since the decom- 
pression of larger blocks increases the overhead, the time 
necessary for decompression is increased as well, especially 
on low-performance platforms like sensor nodes. This fact 
becomes significant if we take into account that the attesta- 
tion has to run in a pseudrandomly manner with nonce as 
the seed for a PRNG forcing a strict ordering of the CI's 
words when calculating the response a; [9]. It forces the 
attacker to decompress each block approximately Sa times. 
Moreover, this disables the attacker to apply a compression 
algorithm Ca that sacrifices performance for higher com- 
pression ratios since the overhead increases for larger block 
sizes Sa recognizably. Therefore, the use of such algorithms 
is easily detectable with the choice of a large block size Sh 
and a threshold Tpm as the upper duration for performing 
compression attacks on the program memory. Obviously, 
e < min{Tem,Tpm} with Tpm > Tem as we will see. 

Figure 2] shows the amount of temporarily decompressed 
data during the attestation, which increases for larger block 
sizes. The attacker has to read about Sa-\Ca{CI)\ bytes from 
the program memory during the attestation if he compressed 
the full CI previously. If the attacker chooses the block size 
to be Sa ~ 2048 bytes and Ca to be PZIP, he will have 
to read up to 37MB from program memory to decompress 
all blocks Sa times and subsequently be able to calculate x. 
This is a huge overhead compared to \CI\ = 25.9KB. For 



the attacker, obviously this huge amount of data is an im- 
mense burden in particular on platforms with low bandwidth 
for reading from program memory. While platforms capa- 
ble of reading 50 AIB/s result in less than 1 second timing 
overhead for 2048 byte blocks, platforms capable of reading 
only IMB/s require up to 40 seconds and thus are easily 
detectable by the proposed attestation protocol. 

Obviously, these overhead to decompress every block Sa times 
impacts the time necessary for the attacker to calculate the 
valid response x for the attestation protocol significantly on 
restricted platforms. As an uncompromised node doesn't 
have to calculate Cj^^{Ch{CI)) at attestation time, i.e. de- 
compress the compressed program image, the block size en- 
ables us to raise and adjust the overhead for the attacker 
by orders of magnitude to let us discover the existence of 
the attacker reliably through a proper choice for the device- 
dependent value of e. However, a larger cache size respec- 
tively Sh slow down the on-the-fly decompression routine 
during normal operation of the restricted device. On the 
other hand a larger cache decreases the number of cache 
misses. Therefore a necessary decompression is more seldom 
for a larger cache size, but takes more time to complete. 

7. SECURITY ANALYSIS 

Our security analysis considers six attack vectors, namely 
7.1 decompressing the code image, 7.2 attacks on the LAT, 
7.3 attacks by using the external memory, 7.4 replay attacks, 
7.5 node depletion attacks, and, finally 7.6 DoS attacks. 

7.1 Decompressing the Code Image 

The attacker is able to decrease the timing overhead by ex- 
ploiting the fact that different blocks can be compressed with 
different compression ratios. Therefore, the attacker could 
pick only those blocks which provide the best compression 
ratios out of all blocks until he gains sufficient memory to 
store his bogus code. Since the blocks are yet compressed 
with a properly chosen lossless compression algorithm, each 
of them provides a similar compression ratio. To overcome 
this issue, the attacker could first calculate C^^(Ch(C/)), 
i.e. decompress the compressed CI and compress it for his 
own afterwards, i.e. calculate Ca{C^^{Ch{CI))). During 
the attestation he then has to calculate Ch(Ca^ {Ca{d))) 
to pass the attestation. Therefore this method further in- 
creases the overhead for the attacker, especially if we choose 
a {Ch,Sh) that compresses rather slowly. Moreover, the at- 
tacker's possible gain is expected to be low, because blocks 
which provide a good compression ratio to the attacker will 
provide a good compression ratio to us as well. 

However, even without calculating C^^{Ch{CI)) the attacker 
still requires to compress only as much blocks as he needs 
to gain enough free memory for the CI. The exact number 
of blocks an attacker has to use depends on our choice of 
{Ch,Sh) as well as the attacker's choice {Ca,Sa) and, obvi- 
ously \CI\ itself. Please note that besides the CI the at- 
tacker has to also store the code of the decompression rou- 
tine Ca^ and the LATa within the program memory. As 
Castelluccia et al. have to spend 1707 bytes for a huffman 
decompression routine [7] used in their compression attack, 
which is a relatively simple algorithm compared to the com- 
pression algorithms proposed in this paper, we force the at- 



tacker to compress at least multiple blocks to get a chance 
to gain enough space for his needs. In general, the attacker 
has to compress 



^Blocks = 



where 



GainPer Block = 



\CI\ + \C-^\ + \LATa 
GainPer Block 

TotalGain 



i^Blockstot 



on average with 



TotalGain = \ChiCI)\ - |Ca(C/)| 



and 



i^Blockstotai = 



\CI\ 



(3) 
(4) 
(5) 
(6) 



\Ca{CI)\ 



The memory overhead then is about ^Blocks-Sa — 
We assume the attacker has to store at least 1KB of datfl 
i.e. \CI\ + \C-^ \ + \LATa\ = 1KB and he wiU calculate 
C^^{Ch{CI)) before compressing CI for his own. For ex- 
ample, if we choose (Ch = PZIP, Sh ~ 512 bytes) and the 
attacker chooses {Ca = PPMZ,Sa = 2048 bytes) the at- 
tacker's memory overhead is about 17.3AIB. Figure [5] shows 
the attacker's possible choices for {Ca,Sa) to gain sufficient 
memory whereas Ch = PZIP with varying Sh is our choice 
of a compression algorithm. For the attacker's choices we 
focus on compression algorithms mentioned in this paper 
only, namely PZIP, PPMZ, ZPAQ and Deflate for block sizes 
ranging from 64 bytes to 2048 bytes. On platforms capable 
of reading 1MB /a of data from program memory, we argue 
that memory overhead above 5MB is easily detectable since 
it slows down the attestation for about 5 seconds. There- 
fore even if we choose rather small block sizes of > 256 
bytes the attack is still detectable. Please note that we do 
not even take the CPU overhead into account here. From 
a security point of view we argue to always use the largest 
possible block size Sh- In practice cache sizes above 1KB 
are hardly feasible, especially on embedded devices with less 
than AKB of data memory. Therefore we propose to choose 
{Ch,Sh > 512 bytes). Please note that other combinations 
will be totally feasible as well, but one has to choose for 
other compression algorithms more carefully. 



7.2 Attacks on the LAT 

The countermeasure to the compression attack is the com- 
pression of the CI with a suitable data compression al- 
gorithm as discussed in Section 7.1. Thus, the only re- 
maining non-compressed data besides the PRW which has 
been argued to be not effectively compressable is the LAT^. 
Consequently, if the {Ch,Sh) for compressing the CI has 
been chosen properly, the only remaining compression at- 
tack is to compress the LATh itself to save program memory 
{Ca{LATh)). If the attacker succeeds in saving enough pro- 
gram memory out of this to additionally store a bogus code 
image CI and at the same time requires e < nnin{T^rn, Tpm}, 



^Please note that this is a very optimistic value from the 
attacker's point of view. 
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Figure 5: The attacker's possible compression 
choices for Ch = PZIP, a varying Sh and a platform 
capable of reading IMB/s from program memory. 

the attack is successful and not detectable by our code at- 
testation protocol. However, recall that a lossless data com- 
pression algorithm does not provide the same compression 
ratio for every ingoing uncompressed data; in particular a 
LAT due to its condensed form can not significantly be com- 
pressed as we will see. Moreover, we state that typically it 
holds \LATh\ << |C/| and |C/| < |PJ?W0. In general, the 
number of entries of a LAT can be computed as 

#Entries{LAT) = ^—^ (7) 
s 

So, even il Ca{LATh) and Ca{CI) with {Ca,8a) would pro- 
vide the same compression ratio, which obviously is not the 
case, the absolute gain of program memory for an attacker 
who purely can compress the remaining uncompressed LATh 
would be significantly smaller. E.g. we assume an embed- 
ded device with 1287^-6 of program memory where \C'I\ — 
25.9KB {multi-hop oscilloscope). We further assume sin- 
gle LAT entries to be coded using 24 bits, i.e. ILAThl = 
^Entries{LATh) ■ 3 bytes for the proposed block size Sh = 
512 bytes. The LATh then occupies 153 bytes. Compression 
results for the LATh of our benchmark applications are listed 
in Table I. For this setting and by applying our countermea- 
sure an attacker's absolute gain of free program memory to 
upload a bogus code image CI would shrink below 5 bytes 
approximateljQ whereas in the absence of our proposed so- 
lution the attacker could occupy approximately up to 17KB 
of the program memory without being detectable. 

Again, with a larger choice of the block size Sh one could re- 
duce the free memory space for an attacker even more. Fur- 
thermore, in case the CI is smaller also the LATh shrinks. 
E.g. if CI is the BaseStatton respectively Sense applica- 

^Typical CI sizes for WSN applications are between 10 to 
60KBytes such that the |P_RW| occupies between 63 Kbytes 
to 113 Kbytes tS- 

''The attacker can choose other compression algorithms not 
mentioned in this paper as well. Although unlikely, other 
algorithms could provide slightly better compression ratios. 



tion and the block size again is Sh = 512 bytes, the attacker 
will not gain free memory by compressing the LATh of size 
90 respectively 18 bytes using the compression algorithms 
mentioned in this paper. Finally, the attacker could over- 
write the LATh within the program memory for his own 
bogus code; in equivalence to the other program memory 
containing compressed code and PRW this attack is de- 
tected by the computation and subsequent verification of 
X = h{nonce\\Ch{CI)\\LATh\\PRW). 



Table 1: Maximum sizes of bogus code images \CI\ 
for Sh = 512 bytes and various applications. 
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7.3 Attacks using External Memory 

The proposed solution detects attacks by the usage of ex- 
ternal memory with the introduction of a device-dependent 
threshold e < Tem. Since the threshold should be as harsh 
as possible there will definetively be cases in which a false 
negative will be the result of a single code attestation run. 
Nevertheless we recommend to choose the Tem as harsh as 
possible to indeed have a meaningful countermeasure against 
an attack in which the attacker makes use of the external 
memory. As a consequence, in case of a false negative one 
should repeat the code attestation protocol n times where 
n is factor two the number of protocol runs in which the re- 
ceived X does not match to the computation at the verifier. 
To restrict the number of iterations for the code attestation 
protocol for a single code attestation phase we recommend 
to stop the protocol in case two times the received response 
X (each time with a different nonce) has been presented. 

7.4 Replay Attacks 

As long as the challenge nonce is always fresh replay attacks 
are not possible. Consequently the size of the nonce is a 
function over the lifetime of the (frequently) battery-driven 
prover and the frequency of applying the code attestation 
protocol. For example if the approximate lifetime of the 
prover is 3 month and the verifier starts the code attesta- 
tion protocol once per hour we state \nonce\ should not be 
smaller than four bytes (this is required to correspond to 
the n chosen in 7.3). The attacker can eavesdrop over the 
wireless all transmitted pairs {noncei, Xi) with the objective 
to resend yet eavesdropped responses Xi. Since the nonce 
is the only data chunk providing freshness for the response 
computation, once a nonce nonccr is repeatedly transmitted 
by the verifier the attacker can use the time slot e to upload 
CI. However, a more realistic attack arises in case of a poor 
implementation of the 'random' choice of a nonce at the veri- 
fier side. If the attacker can infer from pairs {nonce\,xi), 
{noncer, Xr) to noncer-\-i he can precompute Xr+i and the 



time to upload and run CI extends from e to the duration 
until the next run of the code attestation protocol. How- 
ever, running bogus code during the time interval of two 
consecutive sent challenge nonces noncei and noncei+i is al- 
ways possible even without performing such a replay attack. 
Thus, a proper implementation of the freshness function has 
to ensure that the attacker cannot even infer a sequence of 
consecutive nonces noncei, ...jnoncei+j with j > 1 allowing 
to run bogus code undetected during an interval [i, i + j]. 

7.5 Node Depletion Attacks 

If the attacker aims at wasting the energy of the non-tamper 
resistant and restricted prover device he could masquer- 
ade as the master device and continiously send challenges 
nonce. Two countermeasures are possible here: firstly, one 
could introduce a master key k which is shared between 
the master device and the prover device such that x = 
hk{nonce\\Ch{CI)\\LATh\\PRW). ThehkQ denotes a keyed 
MAC. However, obviously this approach contradicts with 
the fact that initially the attacker has full control over the 
non-tamper resistant device such that the k can be read 
out for subsequent depletion attacks. Due to this reason we 
propose a lightweight approach in which the prover device 
computes and sends at maximum n times per epoch a re- 
sponse X. Here n corresponds to the number of iterations 
recommended under 7.3. 

7.6 Other Attacks: DoS 

The protocol is not resistant against DoS attacks. To suffi- 
ciently handle depletion attacks or attacks on the usage of 
the external memory an attacker can always enforce the code 
attestation protocol to stop. In such situations the master 
device considers the code image running on the prover device 
as bogus. 

8. CONCLUSIONS AND OPEN ISSUES 

The work at hand presents a code attestation protocol which 
in particular detects compression attacks aiming to run bo- 
gus code in an undetected manner. The code image is loaded 
in a compressed manner. Only LAT and PRW are loaded 
uncompressed. The presented approach is work in progress. 
Surely, more elaborated analysis are required on a proper 
choice of parameters like Sh, Tpm and n. Also the role of the 
cache needs to be evaluated more in depth with respect to 
potential security weaknesses. 

9. ACKNOWLEDGMENTS 

The authors are most grateful to Aurelien Francillon and 
Claude Castelluccia who gave insightful comments on their 
related work. The work presented in this paper was sup- 
ported in part by the European Commission within the 
STREP WSAN4CIP of the EU Framework Programme 7 for 
Research and Development (http://www.ist-ubisecsens.org) 
as well as the German BMB+F SKIMS project. The views 
and conclusions contained herein are those of the authors 
and should not be interpreted as necessarily representing 
the official policies or endorsements, either expressed or im- 
plied, of the WSAN4CIP project, the SKIMS project or the 
European Commission. 



[1] Wolfe, A., Chanin A. Executing compressed programs 
on an embedded RISC architecture. ACM Sigmicro 
Newsletter, volume 23, pp. 81-91, (1992) 

[2] Lefurgy, C, Bird, P., Chen, I., Mudge T., Improving 
Code Density Using Compression Techniques, 
Proceedings of the 30th annual ACM/IEEE 
international symposium on Microarchitecture, pp. 
194-203, (1997). 

[3] Huffman, D.A. A method for the construction of 
minimum redundancy codes. Proceedings of the IRE 
40 (1962). 

[4] Seshadri, A., Perrig, A., van Doorn, L., and Khosla, P. 
K. SWATT: SoftWare-based ATTestation for 
embedded devices. In IEEE Symposium on Security 
and Privacy (2004), IEEE Computer Society. 

[5] Seshadri, A., Luk, M., Perrig, A., van Doorn, L., and 
Khosla, P. SCUBA: Secure code update by attestation 
in sensor networks. In WiSe S06: Proceedings of the 
5th ACM workshop on Wireless security (2006), ACM. 

[6] Shaneck, M., Mahadevan, K., Kher, V., and Kim,Y. 
Remote software-based attestation for wireless sensors. 
In ESAS (2005). 

[7] Claude Castelluccia, Aurelien Francillon, Daniele 
Perito and Claudio Soriente, On the Difficulty of 
Software-Based Attestation of Embedded Devices, 
ACM CCS 2009. 

[8] H. Yamada, D. Fuji, Y. Nakatsuka, T. Hotta, K. 
Shimamura, T. Inuduka, T. Yamazaki, 
Micro-Controller for reading out compressed 
instruction code and program memory for compressing 
instruction code and storing therein, US 6,986,029 B2 

[9] AbuHmed, T. and Nyamaa, N. and DaeHun Nyang, 
Software-Based Remote Code Attestation in Wireless 
Sensor Network, Global Telecommunications 
Conference, 2009. GLOBECOM 2009. IEEE 
[10] Abadi, M., Budiu, M., Erhngsson, U., and Ligatti J., 
Control-flow integrity. In CCS'05: Proceedings of the 
12th ACM conference on Computer and 
Communications Security (2005), ACM. 
[11] Ferguson, C, Gu, Q., and Shi, H., Self-healing control 
flow protection in sensor applications. In WiSec'09 
(2009), ACM. 

[12] Yang, Yi and Wang, Xinran and Zhu, Sencun and 
Cao, Guohong, Distributed Software-based 
Attestation for Node Compromise Detection in Sensor 
Networks, Proceedings of the 26th IEEE International 
Symposium on Reliable Distributed Systems 



10. REFERENCES 



